Many businesses (and other organizations) use software applications (and/or suites of such applications) to organize their business affairs, track business performance, and/or the like. Such applications (referred to herein as “enterprise applications”) are often quite complex, relying on numerous database tables to store and manage data for virtually every aspect of an organization's business. Merely by way of example, enterprise applications can include supply chain management (“SCM”) applications that manage raw materials, work-in-process and/or finished products, coordinate with suppliers, and/or the like; customer relations management (“CRM”) applications that are used to track, store and/or manage customer information; financial applications that track and/or analyze the financial performance of the organization; human resources applications that provide management of the human resources functions of the organization; and/or the like. In some cases, these enterprise applications are standalone applications; in other cases, a single enterprise application (and/or suite of applications) might provide some or all such functionality. One type of enterprise application is referred to enterprise resource planning (“ERP”) software. Examples of enterprise applications include, without limitation, JD Edwards EnterpriseOne™, PeopleSoft Enterprise™ applications, and the Oracle eBusiness Suite™, all available from Oracle Corporation.
For a variety of reasons, a modem business (or other organization) may be organized into several business units. (A “business unit,” as that term is used herein, means any group or function within a business that is viewed as a discrete entity for one or more purposes, such as for financial responsibility, for managerial reporting, for legal reporting, and/or the like.) These business units often are organized hierarchically in several ways. Merely by way of example, an enterprise might have a legal structure (i.e., a defined structure of corporations organized under the laws of one or more national or regional jurisdictions), a business structure (e.g., a defined organization of divisions arranged according to lines of business), and/or a functional structure (e.g., a reporting structure organized according to function, such as sales, human resources, research and development, etc.). Collectively, these modes of organization define a structural hierarchy of the enterprise, and each business unit typically resides at a certain point within each of these hierarchies.
As an enterprise deploys any application suite, it will need to represent both the internal and external reporting requirement in its enterprise structure. All enterprises must report to external investor and governmental bodies for each legal entity in the enterprise. An enterprise may organize for management and internal reporting in different ways. It is very likely that the management structure of the company influences the representation of business units within the enterprise application.
Thus, in implementing an enterprise application, it is important to understand the structural hierarchy of the organization for which the application is being implemented. For example, it is necessary to understand which business units have independent financial responsibility, so that a financial application can track and report on the individual finances of such organizations. Similarly, it may be important to understand where in the legal hierarchy a particular business falls; merely by way of example, a business unit might be subject to different employment laws, tax laws, export laws, etc., depending on which legal entity it is a part of.
Thus, a primary consideration in implementing an enterprise application for an organization is the identification of the various business units within the organization, and where each business unit falls within the structural hierarchy of the organization. In particular, the data structures of the enterprise application (including, inter alia, the structure and/or organization of the database tables on which the application relies) should model, or at least account for, the structural hierarchy of organization (that is, the organizational structure of the enterprise). Failure to account for the structural hierarchy of the organization when implementing an enterprise application generally will result in an unsatisfactory experience with the application, and possibly can require expensive re-engineering of the application at a later time.
Nonetheless, in the past, enterprise applications have not provided satisfactory tools for ascertaining the structural hierarchy of an organization, or for accounting for that structure when designing the data structures of the application's implementation. Merely by way of example, implementers in the past have had to resort to a time-consuming, iterative process of interviews with key executives to identify the various business units within an organization, and where those business units fall within the structure of the organization. Moreover, even after the completion of the process, it would often be discovered that certain business units had not been properly accounted for. Finally, even after the structure of the organization had been identified, mapping this structure into the data structures of the enterprise application generally required a manual, time-intensive process.
Hence, there is a need for more robust tools for identifying relationships between the various components of organizations, and/or for defining data structures of enterprise applications to account for these relationships.